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IT. INTRODUCTION AND BACKGROUND 





A. INTRODUCTION 
1. Focus 

Although computers are being used for many 
applications in the military, the area of tactical decision- 
SUmpOrt 1S of thewmost critical ispportance. This area 
combines the many aspects of typical business @ecision- 
SUPpOrt with an urgency which is only found in the practice 
of war. The Tactical Ccmmander must select a course of 
action which will result in the attainment of certain goals 
(e.g. the destructicn cf enemy forces or the survival of 
one's own forces). 

It is the potential for the less of many human lives 
and, more importantly, the consequences of failure in the 
political-military effort which makes this problem so 
critical. Because of its crucial nature, tactical decision- 
Support is the area where we will focus our design. 

2. The Problen 

Simply stated, the problem is to provide the 

tactical commander with decisicn-support which is responsive 


tc his needs under all circumstances. We will adopt an 








approach to this problem which we feel will be different 
freom current systems, and which represents an alternative 
that will prove beneficial. The difference is in the way we 
Will approach the problem, and in the way in which we 
contrcl the solution to the problen. We believe our 
approach will result ina more flexible, extendable, and 
adaptable systen. 

Current systems, e-g. the World Wide Military 
Command and Centrol System (WWMCCS) and the Naval Tactical 
Data System (NTDS), approach the problem from the top down. 
The theory is that if conflicts can be managed at the task 
force, division, or theater level, then the conflicts will 
be concluded successfully... 

The complexity of such systems is staggering, with 
tens cf computers linked closely together and communicating 
with far-flung unitS using radio-frequency bands. We will 
approach from the opposite direction, with the belief that 
well-controlled regiments produce weli-controlied divisions, 
BacmeeieEomtea divisions result in centrolled arnies. Our 
emphasis is on providing support to the lowest level of 
tactical commander, whether he is a ship captain or an 


actmored company commander. 
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Only recently has this need to provide low level 
Support in tactical decisicn-making been recognized in the 
Mijitary, and many units still have no capability of this 
Kind. Attaining this capability will be a major gcal of our 
design, and this will be evident in the size and speed 
considerations for the proresed sclution. 

Additionally, we feei that current systems do not 
take advantage of the full capabilities of computer systems, 
and do not use intelligence in the computational 
Manipulation of information. We want to do more than 
display the information ina way which promotes decision- 
Making: we want to bring the formidable abilities of the 
machine to bear on the important tasks -of-analysis and 
response. One approach to accomplish this is the 
MmrecePOra+1On Of artificial intelligence into the tactical 
decision-support system (TDSS). Although most systems use 
mreel@egence, the explicit use of artificial intelligence 
*echnigues has not keen executed. We will use artificial 
mieerrigence (AI) in our soluticn. 

A very Ceivencal, perhaps the Nose crits Cad, 
shertcoming of current systems is the difficulty encountered 
mae adape=ng the TDSS to changing Penn eats. In the 


practice of war, ‘tactics and weapons technology can change 
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SO guickly that successive battles between forces are guite 


different. A TDSS, to be truly responsive to the needs of 
the tactical commander, must be able to adapt to these 
changes rapidly. Current systems require the development 


and distribution of new tactics inthe form of software 
packages t~o adapt to the changing environment. Our proposal 
ls to treat changes to these tactics, and the resultant 
Changes in software flow-cf-control, as information which 
the TDSS manages, just the same as if it were data about the 
Satvation. This will, we believe, produce graceful systen 
adaptation in the face of rapidly changing tactics. 

Our design is presented at the uppermost logical 
level, where most of the actual implementaticn will be 
transparent to the reader. Thus, we will not delve into the 
thecry of AI nor into that of database management systems, 
although both are important to the overall design. We will 
instead concentrate on those areas which are different fron 
Gurcenc solutions, and therefore less familiar to the 
reader. At this level, the capability for intelligent and 
adaptable decision-support will, hopefully, be evident. 

Finally, we will make no claims as to the final 
performance of such a system, although we may at times speak 


as though such a system exists. It does not exist, and any 
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Claims of 2ither laudable or deplorable performance are 
Matters of speculaticn. 
B. APPROACH TO THE SOLUTION 
1. Information, Intelligence, and Decisions 
a. Intelligence 

For our purposes, we will consider intelligence 
moO be wethe ability +o consider froblems and process 
information to achieve some goal or group of gcals, using 
Knecwn resources {Ref 1: p.806]. Thus, intelligence is the 
accumulation and analysis c£ informaticn, and the 
consideration of that information in making decisions. 
Simply put, intelligence is the use of information in 
mecobem@® solving. [Ref 2]. 

b. Data 

The information which the human gathers using 
the senses we classify as "data." The purpose of data is to 
represent the real world, or the environment, to the 
intelligent agent. For humans, the images produced by the 
eyes, ears, nose, and the senses of touch and taste are the 
world with which they deal. The representation of the world 


in this way is the central contributicn to comprehension. 
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Concepts which can not be represented in this manner are 
more difficult to understand (e.g. relativity theory and 
quantum physics). 

c. Knowledge 

To this data humans apply rules. These rules 
allcw chem to use the data in decision-making. Like data, 
meewsu.es aze infortiation, but different in nature. They 
are obtained not merely by sense, but by learning. 
Experience, belief, interpolation, and extrapolaticn are all 
used by human intelligence to validate rules. 

These rules we classify as "knowledge." It is 
data about data and it is used to understand what data 
represents and how to manifulate and analyze-data to-achieve --—- - 
scme end (goal). 

d. The Intelligent Process 

The human intelligent process 1s the gathering 
of sensory data, combined with its perception. Perception 
begins with the formation of a representation, called a 
percept, trom the raw data. The resulting percept may be 
matched to a representaticn already in memory, somé€times 
called a concept. Recognition takes place when a match 
occurs, and when a match is not made, the percept is not 


reccgnized. Knowledge is used ineethe forfation and 
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Manipulation of percepts and concepts [Ref 3: pp. 55-56]. 
Therefore, the human uses two types of information, data and 
kKncewledge, and the intelligent process is impcssible without 
mec D'. 

e. Human versus Machine 

Although computers and humans are obviously 
different in nature, the human mind and the central 
precessing unit (CPO) of the computer are similar in many 
ways. A brief example might suffice. A human job foreman 
is given the task cf Se his resources to meet some 
pre-defined objective. He has constraints placed upon hin 
frem various sources: all jobs assigned must te accomplished 
enn “a Certain™tsne-frame: ~~he™™ hass-a known -lrmit +to-- 
available personnel; he is expected to get maximum use of 
his assigned personnel; and job turnaround time is expected 
#6 be eatnigized. 

These constraints represent some of the rules 
under which ¢he foreman operates. The data he uses are the 
jors assigned, job requirements, and so on. Using this 
information, the foreman schedules the work and monitors 
progress. 

We contend that the foreman's task is one which 


reguires intelligence. The analogy to the computer follows 
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ped serguable, but computers need this explicit distinction 
tc cperate efficiently. It should be noted that humans need 
not make such explicit categorizations and the distinction 
varies depending upon the problem being considered. 

Implementation cf cur design will make use of 
"artificial insight" in the use of dense indexes especially, 
as well as other methods. Although this will result in 
increased storage (space) regquirements, the time saved is 
considered worth the additional space. 

f. The Decision Process 

we believe that the process of decision-making 
adheres to a few fundamental principles. First, information 
is gathered and added to the store of information already 
onhand. 'Predecisions" are made during this phase, such as 
what action +o take when inconsistent information is 
encountered. These predecisions are judgements which are 


made to reduce the ambiguity of the situation represented by 


the information. Predecision uses knowledge about 
eertO=Macion limitations, in ensuring that information 
conforms *o «hese limits. Both data and knowledge may be 


accumulated during this phase. 


Next, the collected information is analyzed to 


acrive atan accurate summary, OL perception, Of ene 
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Situation. This analysis consists of the consideration of 
various aspects of «che situation, and usually involves a 
computation tc arrive at a summary representation. 


Then, the decision process compares <ie 


resources used by the various solutions considered during 
analysis, and compares the results of each of the solutions. 
Each result will have some relative value to the decision- 
maker. A good, rational decision would be one in which the 
rescurce expenditure and the goal achievement were 
Setiprzed. 

The whole process can thus be decomposed into 
three phases: acquisition of information; analysis; and 
decision. The outcome cf the process depends on the 
successful execution of all three phases. 


2. The Tactical Envircnment 





For our application area, that of tactical decision- 


making, our chosen scenaric is as follows: 


A U.S. naval vessel is at sea during a period of 
escalating international tension. Inrtormation concerning 
potentially hostile vessels and aircraft is available to the 
ship's Tactical Action Officer (TAO) from various sources: 
intelligence sources, his own ship's sensors, etc. The TAO 


is faced with the task of identifying, by type and threat, a 
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host of potentially hostile coOntdets. All available 
=nfcrmation must be used tc the greatest extent possible to 
maximize the chance of survival in “ene event that 


hostilities break out. 


Several assumptions are made concerning the nature 


omer he tactical situations which we forsee: 


e Peacetime behavior may bear little or no 
resemblence to behavior during the various phases of an 
escalating crisis. 

e Electronic warfare will be used to deny 
hostile forces the use cf sensorsycommunications and to 
ensure friendly forces use cf the same. 

e Long-range strikes will include combinations 
of platforns with varicus levéls cf intelligent control 
(cruise missiles, tactical ballistic missiles, manned 
aeincratt) . 

e Rules of engagement (ROE) Will change rapidly 
during escalation phases of a crisis, probably using 


combinations of predetermined rules. 


we shculd emphasize that our choice of scenario is 
purely arbitrary. A land-based missile battery or a 
squadron of bombers would face Similac Situations and 


cizxcumstances. The problez is cf a generic nature. 
us. 





Methods of attack are fast, Wien, Life le cor no 
Warning, and they are deadly, with a single hit powerful 
encugh to destroy or disable most modern units. Two factors 
Meee be Bost critical inthe struggle to survive in a 
hostile 2nvironment: mobility and flexibility. We should 
have learned from the "great" wars of history that no amount 
of firepower will offset a weakness in either of these twe 
areas. The tactical environment is predominantly one of 
rapidly changing circumstances which affect the various 
decisions of the commander. On an individual basis, each 
tactical commander's goal is to win the first battle of the 
next wat. Situational uncertainty will severely hamper 
sentegang =his goal. 


Sub-sonic, ground~skimming crulse missiles or super- 


Sen.c, high-altitude missiles, both equipped with 
conventional warheads, Will probably present the worst 
ete t . In either casé, assumMing current technology, the 


time from initial detection of the missile to impact will be 
approximately seven (7) minutes. Thus, the tactical 
commander will have a limited amount of time to process a 
large amount of information and make critical decisions 
regarding his unit's survival. The commander's most 


effective use of all of his available resources is largely 
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dependent upon his overall knowledge of She @arrent 
situation. The need for accurate and up-to-date 
intelligerc2 information is magnified when one considers the 
scenario described above. #e must provide the commander 
this information to assist him in making the correct 
decisions concerning mobility, flexibility, and survival. 
3. Reguirement for Adaptability 

At this point it must be re-emphasized that the 
weactical environment is one of rapidly changing 
circumstances. Military forces in peacetime train to fight 
the type of warfare which is expected in the next war. 
Historically, predictions cf future conflicts have been poor 
(at least <those-by the military leadership -entrusted with 
@eetsinaal training). 

The fruitlessness of some predictions can be 


gathered from «he fact that most of the standing armies of 


Europe (and the JU.S.) had combat cavalry units at the 
Sucbreak of World Wat I, althcugh the principal warfare of 
that era turned out to be trench warfare. At the beginning 


of World War II, the concensus among the Aliies was that 
battleships and the Maginot Line would be the predominant 
factcers: of course, aircraft carriers and blitzkrieg quickly 


ended that thougnt. We could gc on, discussing the 
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Surprises of Vietnam or the Six Day War, but the lesson is 
already clear: den't become entrenched in the tactics 
practiced in peacetime. 

What is expected in peace may have lottie 
resemblence to what happens in war. Secrets are kept which 
are designed to produce uncertainty, throwing the enenry off- 
balance long enough to exploit his weaknesses. The 
inability to adapt to meet unpredictable threats gquickly 
encugh is the most fatal flaw a military commander may 
posess. Conversely, the ability to adapt and take advantage 
of new circumstances has long been the nailmark of great 


military genius. It is this adaptability which we feel is 


lacking “in-curren+ ccmmand-and»control-systems;- and which=we-- 


have included in our system as a salient design feature. 


PADD 
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If. GENERAL SYSTEM DESCRIPTION 


A. PREFACE 

This chapter ccnsists cf three separate secticns. The 
first section provides a general description of the major 
components and characteristics of a typical knowledge-based 
computer system. This is intended to acquaint the reader 
with the basic concepts underlying our decisicn-support 
systen, TAC®. THEN, dhat we feel is a practical and 
understandable example is given. This example should 


prcvide the reader with a basic understanding of the 


operation of-an intelligent; adaptable-system.- Finally, the ~ 


basic syst2m configuration and operation of our deésign is 
presented. 
B. GENERAL 

There are many possible variations for a knowledge-based 
decision-support system, but they all consist of three basic 
components in one form or ancther. Such a system may be 
theught of as being a composition of a database, some sort 


of control mechanism, and a set of rules [Ref 4s p. 4]. 


The database (DB) is merely a repository for all of the 


current data about the environment. m=. 1S aeco! lec=j0n. of 
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all known facts. AS cne would surmise, a dynamic 
environment implies that the DB is continually being 
updated. Additional informaticn, mere recent information, 
and entirely new information are tne three types of data 
that are stored Zn tie 7eDE. The following example 
lnecrporates the three types of information. 

Information concerning the retail price of an 
autecmobile may be stored in the DB. As information about 
sales volume becomes availatle, the inclusion of this data 
into the DB would constitute additional information. 1056 - 
due to inflaticn, the retail price for the automobile is 


increased by, say $200.00, this new price would represent 


mcre recent information. When an entirely new model of 
automobile is introduced on the market, Such information 
would be classified as new information. The DEB does not 


analyze any type of informaticn, but merely stores it. 


The rules may be thought of as being a disjoint set of 
conditions which have unique responses associated with each. 
In programming, this is analagous to a series of “IF...THEN" 
statements. It is through these rules that an understanding 
of the data stored in the DE is achieved. Like the data in 
the DB, these rules may also undergo change based upon the 


environment. Three types of change are possible: addition, 
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moceson, and revision of rules. New rules may need to be 
added when a changing environment creates a situation that 


is not currently covered by the existing set of rules. When 


the environment changes, some rules may no longer be 
applicable. Rather than occupying space in the systen, 
these rules Should be deleted. Also, different 


circumstances may trigger a need to revise an existing rule. 
We will call the repository for system knowledge about the 
environment a knowledge base (KB). The combination of a 
dynamic DB anda dynamic KB work in concert tn provide a 
consistent view of the real world for the system user. 

The responsibility for insuring that necessary changes 
are made lies with the control mechanism. All inputs to the 
systen first pass thrcugh the controller where a 
differentiation is made between pure data and rule changes. 
Data is sent to the DB while rule changes go to the KB. Be 
might be convenient to think cf the controlier as an 
interface between the DB and the KB because it is inthis 
component where applicarle rules are applied to tne 
corresponding data, changes to both the DB and KB are 
initiated, and appropriate action (or non-action) is 
determined. Thus, the controller is the heart of the 


knewledge-based decision-support systen. 








The preceding section has given a very basic overview of 
a knewledge-based decision-support systen, describing the 
three major components. Although such a system is much acre 
complex than this summary indicates, especially when cne 
considers the possible system variations, an attempt was 
made to lay the foundation for understanding the detailed 
explanation of our prototype system, TAC*, which follows in 
Chapter III. 
C. PRACTICAL EXAMPLE 

As an example of the operation of an intelligent and 
adaptable system, we will consider a professional football 
t2am. This example is understandable for most people and 
alsc has a direct analcgy to the operation of our decision- 
Support systen. In the tactical environment, the overall 
Medinis tO win the battle. Similarly, on the football 
field, the goal is to win the game. 

1, Resources 

Because the total number of players a team may have 

momceriGcly ccntrolled, there is a definite limitation to 
*+he coach's available resources. However, the athletic 
Botential, Or capabilities, of all players is not controlled 
ner are these capabilities identical. Therefore, the 


overall quality of a team's resources wili vary from one 
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professional organization to another. The ccach must 
attempt to win each game based upon these number and quality 
constraints. 
2. Game Preparation 

POOeDal! teamS practice in preparation for actual 
games. The overall game strategy and specific plays are 
developed based upon what is expected to occur during the 
game. Thus, a certain amount of prediction is necessary in 
preparation for the game. The coaches are trying to predict 


(into the future) those plays that the opposition will try. 


Before each game, the opposing team's strengths and 
weaknesses are studied. Data about the other team's 
tendencies is accumulated and analyzed, thus giving the 
coaching staff scme knowledge about the Opponent. 
Eventually, the coaching staff arrives at conclusions as to 
what the other team is likely to do in specific situations 
threughout the game. (Since each team has different 
strengths and weaknesses, these conclusions will change fron 
game to game.) The conclusions are then written dcwn in the 
form of plays that the team will use during the game. Phas 
seguence of plays is called a "game plan." In essence, the 
plays are the rules that the team will follow throughout the 


contest. There is ancther type cf rule which the tean 
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follows in both the preparaticn for and the actual play of 


the game. These are the rules cf the league. For example, 


each team may only have eleven players on the field during 


the execution of a play, an offensive player may not block a 


defensive player below the waist, etc. Both types of rules 


are combined and determine the flow of action during the 


game. Incidentally, those league rules are enforced by the 


referees lin an actual game. Generally speaking, the 


referees oversee all acticn cn the field. When a team's 


action or formation conflicts with the league rules, the 


referees assess a penalty against the offending team and, 


m@nuis, resolve the conflict. 


In summary, then, at the opening- kickoff, - 
has accumulated data about the cther team and each has been 


able to gain some knowledge about the other based upon the 


analysis of the data. 


3. Playing The Game 


At the outse+ of the game, ateam wants to follow 


the overall strategy as defined in its game plan. Por 


example, ina particular situation, the plan may call for 


the quarterback to throw a short pass to the tight end ten 


from the line of near the sideline. 


each tean-.- 


yards 


However, the 


coaching staff realizes that 


scrimmage and 


their opponents 
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may try to win the game by making changes to their own plays 
during the course of the game. These Changes may render a 
particular play ineffective. Fcr example, the opposing tean 
may decide to have two defenders play against the tight end, 
instead of one, and the sideline pass mentioned above may 
net be able to be completed with the new defensive coverage. 
Therefore, the coaching staff will have several personnel 
positioned high above the field to detect any such changes 
in the defensive coverage and suggest alternate plays to 
call which will be effective against the new defense. A 
gocd choice might be a play run earlier which was successful 


against the opposition's present defense. This would entail 


prejecting. back..in.time. to...find the. successful play. This _. 


grcup of people monitors the acticn on the field, but 
becomes the controller of the action when changes occur. [In 
essence, the group determines when the game plan is ao 
longer effective and tries to adapt to new situations by 
changing the rules that their team will follow during the 
remainder of the game. Further, their recommended changes 
must be made as quickly as possible to preclude the opposing 
team from dominating the action and ultimately winning the 


game. 
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4. Summary 

A successful professional footbail team may be 
Characterized as being an intelligent organization which 
utilizes data to derive kncwledge about its opponents and an 
organization which is capable of changing the rules under 
which it operates when the situation changes. The catalyst 
which insures that the team is rapidly adaptable is the 
greup of contrellers positioned akove the action on the 
field. While this group selects a particular play that will 
hopefully be successful, the quarterback makes the final 
decision as to which play is actually to be run. For 
example, if the group tells the guarterback to run play "x", 
and when the team deploys at the line of scrimmage, an 
unexpected defensive alignment may be applied by the 
oppesing tean. So, the quarterback will change the play to 
be run by calling a special set of numbers at the line of 
scrimmage which signify play ‘y." 

The next section should reflect a remarkable 
Similarity between the operaticn of a professional football 
team and the operation cf our tactical decisicn-support 


system. 
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D. TAC*®: BASIC DESCRIPTION 
Essentially, TAC*® 1s an intelligent computer systen 

Which utilizes current information about the real world, 
steered in its dynamic "“infobase", to understand changes 
which occur in the real world. Besides the routine changes 
which occur due to the passing of time or the movement of 
units, a change may also signal a "conflict" between data 
items and knowledge rules. A conflict is an inconsistency 
reguiring a decision by some agent which results in a 
consistent database. A conflict may be classified into one 
of three areas: 

dus Those that occur due to technological or 
infcrmational limitations; é€.g. Two known ships pass within 
"x meters of each cther. Both ships are being tracked, 
however there exists an area wherein it becomes impossible 
to differentiate between these ships. This resolution 
limitation of our current technology poses obvious problems 
in determining which ship is sailing what course as both 
emerge from the ambiguous area. 

2 Those that require Ferward Predictian; e.g. 
Intelligence sources are tracking a flight of known hostile 
planes when, suddenly, the flight disaprears. It is 


imperative that we be able to project forward in time giving 
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the ultimate <target, or at least the heading, fer this 
flight of hostile planes. 

3. Those that require Backward Prediction; e.g. 
Intelligence sources report a troop build-up of known size 
has occured during the past 24 hours in Eastern Europe. de 
must ascertain whether the force is mechanized cr armored, 
Merci Other units might be ine support, etc. Backward 
Prediction allows us to project tEackward in time to a 
verified, real-world situation in order to ultimately 
identify the unit in question. Tine, distance, overall 
logistics capabilities, available means of movement, etc. 
must be considered. 

As can be seen from the above examples, TAC* should 
preve to be an invaluable tool in both tactical and 
strategic planning, with specific applications for all 
branches of the military services. 

The three major components of TAC*® are the controller 
(CCN), the database management subsystem (DBMS), and the 
knewledge base management subsystem (KBMS). Pies Gon eso 
may be thought cf as a "world watcher" Wicca se oe 
responsibility of taking centrel cf the system when a 
conflict arises or information changes are needed. Direct 


interaction with the database manager (DBM) insures that the 
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results of all updates to the datakase are known by the 
Semerolisr, thus insuring that all conflicts are detected. 
Corresponding to the database is a knewledge base which, in 
essence, is a set of rules that the database must abide by; 
i.é€. an armored brigade cannot move 1000 miles in a six hour 
period, or an aircraft carrier is net capable of making a 
180 degree turn within a 200 meter space. Such restrictions 
might be termed "data constraints." 

This brief overview of TAC*® should be adequate to 
preceéed on a common level and, hopefully, will enable us to 
understand the detailed system description which follows. 
Then we will be able tc focus our attention on specific 


sclutions to specific. problems. 
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rites DETATIEDE Ss CHIE 


A. REAL-WORLD REPRESENTATION 

The purpose of TAC* is to analyze the real-world and, 
based on cules provided to the system, to advise the 
decision-maker on a course of action. To do this, TAC*® must 
be able to understand the real-world. The real-world is 
represented to TAC* by the database (DB). A DB is a series 
of records which contain information about objects and their 
relationships with cther objects. 

BeeeeeGOrd is a structured collection of data, each 
sutstructure of which is called a "field." These fields 
represent abstract properties of an object, called 
"attributes." Each attribute has an asscciated value. The 
fields of a record contain values for the attributes of the 
object which is represented by that record. 

1. Areas of Interest 

The example we have chcsen is of a naval vessel on 
the open sea (i.e. no land mass). The area surrounding that 
vessel is its "area of interest" (AOI). An AOI represents a 
section of the real world. Position within an AOI will be 


represented using a coordinate systen. Notice that the 
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definition of AOI depends upon the point of view (tactical 
responsibility) of the user command. FOE the wseint Chiefs 
of Staff, the entire globe may be their AOI. However, for a 
Single small unit, the AOI will generally correspond to the 
@eca in Which the unit is operating. The size cf the are2a 
w2il depend on the capability cf the unit and the limits of 
the defense perimeter. 
2. States 

The condition of a system can be described in terms 
of its "state." State is the term which we shall use to 
identify the condition of the TAC*® systen, the real~world 
Situation represented in the TAC*® DB, and the individual 
object~records in that DB. 

An object state will be that combination of record 
fields which describes the status of the object. For most 
objects, this will ccmprise the position, identification, 
and warfare status fields. Certain rules in the KB will 
pertain to allowable object transitions from one state to 
amether. Only transitions which obey these rules will be 
allewed +o occur automatically. Transitions violating these 
object transition rules may be held pending and made known 
to the system operator. Only valid cbhject state transitions 


will be permitted. 
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An area state value describes the evaluaticn of an 
seca) oie, interest. Area states take on values which 
represent a tactical view of the AOI. Ship types and 
capabilities, relative positioning and political situations 
all ccentribute to the evaluaticn of an area state. Area 
states are Summaries of all of the local (object) states 
Within that area. A change to a local state may affect the 
area state, but an area state cannot change without a change 
to an object state. 

Area state values are determined by object states. 
They are computational and analytical summations of the set 
of cbjects included in that area. The area state value is 
determined follcwing each valid DB ufdate. It is this area 
state which the system uses to determine what action, if 
any, to take. 

The system state takes cn values which describe the 
current system status. For example, the system may be 
"idle" with no pending operaticns. Or it may be updating 
the DB, or analyzing the results of an update, or updating 
the KB. 

we avoid the use of local and global states to avoid 
ambiguity. Instead, we will consider object states and area 


states and their associated transiticns. Depending upon the 


36 








sccpe of the system and the rules in the KB, an object in 
one system nay b2 an area (AOI) in another (smaller) systen. 
In our example, we deal with a single ship's system, and 
therefore the objects are cther individual platforms and the 
area is the ship's AOI. 
8. DETAILED MODULE DESCRIETIONS 

1. Interface 

ae Input 

Our system is essentially symbiotic in nature, 
relying upon raw information from other sources to feed its 
database. In order to do this reliably, an input subsysten 
with appropriate capabilities must be used. 

The system 1S message oriented and designed to 
operate with multiple inputs and with multipie priority 
messages. Three major source classes for messages must be 
considered: system and operator generated, intrinsic sensor 
generated, and externally generated. 

System and operator generated messages are the 
easiest to handle. System messages occur only as a result 
of some state change. When a new state vaiue has as its 
action a data or rule transaction, the system generates a 
message which is fcrwarded to the input spooler (via the 


outfut spooler). Next, the operator may enter a message to 
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the systen. Most KB changes, and some DB updaté/request 
messages will be created in this way. 

The next most impertant general source class is 
intrinsic sensor. Sensing devices on the user platform will 


have a message formatting translator to allow direct input 


@oeche input spool. These inputs from ship sensors (radar, 
sonar, ESM) will be multiplexed and queued according to 
PEaority< 


The final major source class is externally 
generated reports. The best examples of these are 
intelligence reports, OFREF-3 messages, NTDS Link 11/14 type 
intercommunication, and UNITREPs. All of this information 
OLTiginates outside the ship and is received via tradio 
receiving units. These radio messages must be 
decrypted/translated and channelled to the input spooler. A 
separate processing system may te needed to do this in order 
to insure rapid access to external data. 

All of these sources meet at one destination: 
the Input Spooling Process (ISP). The purposes of the ISP 


ate. 


e To collect, merge, and sort the inccming data 


qugekiy. 
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es iceact 45 a2 (<@uefer during high #olume traffic 
periods. 
e To feed transactions one at atime into the 


Input Selector Switch. 


The ISP may be considered to be a smart queuing 
device. If it is expected that large amounts of data will 
be incoming, the System may schedule _ the ISP more 
frequently; more sensibly, the system design is amenable te 
Some multiprocessing and the ISP could easily use a 
dedicated processing unit¢. 

b. Output 

Like the Input Spooling Process, the Output 
Spcoling Process manages the flow of information out of the 
system. Output destinations fall iro four ma jor 
categcries: operator, system, intrinsic, and external. 

Operator messages are advice or orders to the 
operator. The result of some rule invocations may be to 
infcrm the decision-maker of a new level of readiness which 
must be achieved. Or it may notify the operatcr that an 
invalid object state transition was attempted, and ask for 
instructions to complete the pending action. 

System message outputs, as mentioned above, 


allcw the system to feed back to itself. Some area states 
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might require this, or a change in a KB item affecting the 
Sieren«e State may produce this result. It saould be 
considered an infreguent action. 

Correlation of two objects in the database may 
meus in Intrinsic sensor acticn. The need for additional 
or mcre detailed surveillance information could also cause 
the system to send a message to a sensor station. For 
example, a report received on an unidentified subsurface 
contact may neglect to include a depth. TAC* may then 
prcempt the sonar team for this infcrmation, or request a 
change in node to determine depth, or estimate it for then 
based on current sea conditions. 

In certain situations, it may be advantageous 
for TAC* to generate messages and send them directly to the 
Navy Telecommunications System for broadcast. Periodic 
Situation summaries or high-priority operational reports 
could be 2asily handled by TAC, enabling the tactical 
commander to concentrate on ties situation at hand. 
Naturally, this capability could be modified to allow human 
intervention and editing prior to transmission, and this 
ability could be disabled during those periods of emissicn 


control when transmission is not desired. 
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As with input the system will handle output 
communications with spooling. An Output Spooling Process 
(OSP) would receive and fcrward output messages to their 
destinations. Multiple spcoling by class would ke used to 
ensure quick response. One spccler would handle the 
operator interface, another the intrinsic sensors, and 
ancther the external broadcast channel. A separate spooler 
is not needed for the system messages, as the ISP will spool 
that class of message anyway. The OSP Intrinsic Sensor 


Spccl could also execute the demultiplexing process. 


2. Control Subsystem (CON) 


D 


The Control Subsystem acts as the highest level of 
control for the TAC* systen. Input to and output from the 
TAC* system are through the modules cf the Control Subsystem 


(CON). CON has two basic functions: 


e To decide the destination of an incoming 
message. 


e To decide the destination of outgoing actions. 


CON has four components: the State Comparison Module 
(SCM), the Log Recorder (LCG), the Response Driver (DRIVER), 
and the Input Selection Module (ISM). The functions of each 


are described below. 
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a. Input Selection Module (ISM) 

The Input Selection Mcdule (ISM) is tne 
gatekeeper for the TAC*® systen. Messages are received fron 
the Input Spooling Process and the determination is made as 
to whether the message is a data transaction (DTX) or a rule 
transaction (RTX). DTX traffic is routed to the DEMS 
Subsystem via the DBMS Ingate. RTX traffic is routed to the 
State Compariscn Module. 

Selection in the ISM is accomplished by a simple 
boolean (bit) check. A message is either a DTX or an RTX, 
but net both. A DTX message is placed in the DEMS Ingate, 
which acts as a mailbox. RTX messages require different 
handling, and are first checked by the State Comparison 
Mcdule. 

b. State Comparison Module (SCM) 

The State Comparison Module (SCM) also performs 
selection, but this is more complicated than the ISM. 
First, the SCM compares the input state to the current area 
state of the systen. Based upon this comparison, and the 
knewledge of where the input state originated, the SCM 
decides where to send the msessage. 

If the input is from the ISM, and the states do 


not match, the message is a rule change requiring no special 
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handling, and it is passed to the KBMS for action. If the 
ISMN is the source and states are the same, the message is an 
RTX affecting the current state, and is sent to the Response 
Fetch module of the KEMS for immediate handling. 

The input may te from the DBMS. Specifically, 
the Area-State Monitcr will send its latest area state 
Summary to the SCM. I£ states do not change, the sessage is 
Simply discarded. If states do change, however, the message 
1s passed to the Response~Fetch module for matching and 
reaction, and the current state is updated. 

Thus, the State Compariscn Module performs quick 


matching to enable rapid system response to new rules or new 


data. 
c. Log Recorder (LOG) 
Another functicn of the CON is to record the 
effects and transactions on the system. This invelves both 


object state transiticns and area state transitions. 
Recording this information allows for smooth recovery of the 
system from crash, fe0m, a Cold wstarte £0 a conSistent, 
accurate D5. 

If properly used, the LOG can also check the 
effectiveness of rule actions. Programs could te written 


which would scan the Log Reccrd and compile statistical 
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performance figures on each rule, thereby allowing the 
pinpointing of faulty assumptions and the correcticn of poor 
performers. During development and tuning of new KB's, this 
cculd be very important, possibly allowing the test of new 
Biec PELOE tO distribution to operating forces. 

d. Response Driver (DRIVER) 

The Response Driver (DRIVER) is the heart of the 
control sub-system. While the KBMS acts as the repository 
for knowledge, the DRIVER implements that knowledge. TE 
receives messages from the KBMS (Response Fetch) and from 
the DBMS (Object Transition Validation or OTV) modules and 
converts them to inquiries, advice, or orders. 

From the KBMS Response Fetch module, it gets the 
result of srule-condition matching, which produces the 
reaction part of the rules stored in the system KB. These 
reactions it converts to device orders or advice to other 
systems. *t may also tell the OSP to send a message to the 
ISE as a data transaction. These possible actions are the 
pregrammed responses +o an area State Summary. 

The DRIVER may also get object transition 
messages from the OTV module of the DBMS, signalling that a 
data transaction is being held pending due to a conflict 


between the DB and the object KB. This prompt is passed to 
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the user to allow him to choose the method of resolution, or 
the DRIVER may be programmed +o make the decision. The 
chcices and the methodology cf the OTV will be discussed 
watcE. 

The DRIVER is the connector to the output for 
she entire system. It is this mcedule which permits TAC*® to 
influence other systems and provide tactical advice. 

The function of CON is to pass informaticn to and 
from the KBMS/DBMS subsystems, and to provide the framework 
arcund which TAC* executes. AS with tne Input and Output 
Suksystems, it is possible that large TAC* systems would 
benefit from a dedicated CON processor which would be 
tightly coupled to the INPUT, OUTPUT, DEMS, and KBMS 
precessés. For small systems, this should not be needed. 
Next we look at the Database Management Subsystem (DBMS). 

3. Database Management Subsystem (DBMS) 

The next major segment of TAC* is the Database 
Management Subsystem (DBMS). It consists of six major 
modules which operate together to represent a reai-world 
situation in data records. The parts of the DBMS allow the 
representaticn to be created, tc grow, to be changed, and to 


be accessed. 
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a. Ingate 

The Ingate acts as the interface between the 
DEMS and the input cf the systen. Recall that the Input 
Selection Module (ISM) od CON sends incoming data 
transactions to the DBMS. These transactions are sent to 
the KBMS via the KBMS Ingate. 

The Ingate is a buffering and queuing process 
which allows the DBMS and ISM te operate at different 
speeds. Incoming transactions are queued and processed in 
order. A pre-emptive queue may be used to ensure that the 
most important updates get top priority. Thus, a high 
precedence message would be expected to go to the top of the 
queue, while low precedence messages would go to the botton. 
Alternatively, an ordering of four seperate guéeues could be 
used. When the DB Management Mcdule (DBMM) is ready for the 
next message, it gets the message from the Ingate. 

b. Database Management Module (DBMM) 

The Database Management Module ({DBMM) acts to 
interpret DB transactions and execute the required change 
orders. Database Management System (DBMS) theory is well 
knewn, and we will not describe the DBMS operation in 


getail. 
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To update a record, the DBMM gets that record 
com the DB. A lookup must be done in the DB Index, a data 
structur2? which is maintained by the DBMM. Io promote fast 
access, we envision a well-structured, dense index. This 


will require more storage than that reguired otherwise. 


Once the record is brought into main storage, a 
quick check must be made to see if the pending transaction 
1s the most recent transaction. If it is not, the pending 
transaction is entered into the archival portion of the 
recerd and the record is put back into the DB. I£f a pending 
transaction is more recent than the most recent already in 
the current record, the pending transaction replaces the 
older transaction, and the older transaction is placed into 
the archival section. Prior to a "put", pending transaction 
results are checked by the Object Transition Validation 


Module (see below). 


Additions of new objects and deletion of old 
records is also done by the CBMM. These operations are 
relatively simple as they cnly invoke the Index and the Free 
Record Queue, DOthe os wWhichereside in the DBILM. It is 
interesting to note that tc be efficient in storage, the DB 


Index and Free Record Queue may themselves be records in the 
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DE, and only be brought inte main storage when needed for 
leckup and management. 

Many ways of indexing and structuring databases 
exist, and we will make no attempt to explain all of then 
nor will we limit the applicability of our system to one 
epecitic type. We feel that the structure of our system 
permits independent (or nearly so) operation of the DBM and 
KBM sub-systems. These managers are isolated from the 
mechanisms by the message-handling modules of the systen. 

c. The Database (DB) 

The Database (CB) is the collection of records 
which represents the real-world to the computer. The DB 
records contain information about objects in the world and 
the relationships between these cb jects. Data about each 
object is divided into two major categories: current and 
archival. The current section is itself a record. hfe 
defines the current state of a physical or abstract object 
in the database. Examples of current data ares: the last 
knewn position report, with asscciated effective time-stamp; 
the generic type identification; and the warfare status. 
Warfare status will define the intrinsic capabilities of 


that unit (weapons on board, damage sustained, etc.). 
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The archival section is a zecord of other 
pertinent information abcut an object. Past position 
BerpcrEts, noOn-tactical information, andwOtCher Nien -pE1oLit y 
data will be retained in the archival section. 

d. Object Transiticn Validation Module 

When an update is received for a specific DB 
object, certain validity checks may be performed to ensure 
that data received is consistent. The Object Transition 
Validation (OTV) Module does this by comparing the proposed 
Change to physical or behavioral rules which are recorded in 
the knowledge base. A data transaction which conflicts with 
a rule of the system will be identified and corrective 
action may be taken. 

For 2xample, a data transaction reports that 
object "x" is now 100 nautical miles (nm) ‘from where it was 
one hour earlier. Object "x" has been evaluated previously 
as a destroyer-type ship. Now the data transaction 
conflicts with the maximum possible speed for surface ships 
of this “ype, which is 35 knots. Either the data 
wommateeion LS incorrect, the cld report was incorrect, the 
evaluation was in error, cr else the rule limiting surface 
Speeds iS wrong. Such ccnflicts must be considered when 
designing a system with imperfect sensory data and imperfect 


knewledge. 
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The OTV Module can handle such a conflict in 
several ways. It may allcw the data transaction to be nade 
and note the existence of the conflict. This would be 
called "data supremacy" because the information included in 
the data transaction is presumed to be correct. Conversely, 
the OTV Module may reject the data transaction, and merely 
nete that the transaction was attempted, but not allowed. 
This would ke called "kncewledge supremacy" because the 
information included in the knowledge base is presumed to be 
GoErect. 

Still another alternative would be tc hold the 
transaction pending and infcrm the ocpferator of the conflict. 
The human could then make the decision as to which 
information item was incorrect, and direct the completion or 
abvertion of the transacticn. Ancther possibility is a 
hybrid version which considers the relative amount of error, 
ance permits "small" conflicts to be transacted. The 
possibilities seem limitless, but all will depend upon the 
Supremacy of data, the supremacy of knowledge, or the 
equality of data and knowledge. Under any circumstances, 


each transaction will either be completed or aborted. 
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e. Area State Monitor (STATE_MON) 

so far, we have just considered the objects in 
Bae — database. Now we must look at the DB as a whole, 
representing the state of the real werld as modelled by the 
computer. What we need from the DB is a statement which 
Summarizes the conditions which exist in reality. The Area 
State Monitor performs this task. 

The Area State Monitor (STATE_MON) considers the 
presence of physical objects in the database, and also the 
values of certain abstract DB objects. For example, the 
abs*ract DB object "Readiness_Condition" will have a value 
dependent upon the declared state of readiness as 
premulgated by the National Command Authority (NCA) or local 
area commanders. Numbers and types of hostile units and 
friendly forces will also cre considered. 

From this data, the STATE_MON extracts a value 
which represents the state of the area of interest (AOI). 
This area state summary is what TAC*® uses to determine what 
reaction is needed/recommended. The STATE MON computes this 
Summary and passes it to the Outgate for forwarding to the 
Log Recorder and State Comparison Module. The STATE_MON 
uses data and knowledge to derive the summary value 


describing the area state. It has direct access to the KBMS 
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Area Analysis Rule Sukbase. These rules may be changed like 
Piyemoev@r item,.in the KBE, resulting in adaptable data 
analysis. 

The STATE_MON is perhaps the most important of 
the TAC*® modules, because it performs the actual analysis of 
Situational data. A sub-Ease of the KB will be accessed by 
the STATE MON, and rules directing the computational 
analysis of data will Fre called and executed by the 
STATE MON. 

In the football analogy, the function of the 
STATE_MON is performed by the group of controllers from high 
abceve the field and by the quarterback as he steps to the 
line of scrimmage. Scanning the field of piay, he notes the 
disposition of the offense and defense, looks for "key" 
indications of defensive intentions, and draws a rapid 
conclusion. For the QB, that conclusion is whether to 
execute the play called in the huddle, or to call a new play 
at the line of scrimmage. Final flay selection depends 
almost entirely on the analysis by the QB, and he typically 
has abou« 10 seconds in which to make his decision. 

In TAC*®, the STATE_MON acts like the QB in 
analyzing force disposition, capabilities, and signs which 


might indicate enemy intentions. Tt does. this 
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computationally, py deriving a value for the Area State 
Summary. Tne Summary is a group cf bits whose value depends 
upcn various asrects of the state. 

Methout actually defining a function for the 
STATE_MON, it may be hard to understand, but the analogy to 
the quarterback is very accurate. Detailed operation is 
dependent on the implementation, and the implementation of 
the Area tate Monitor will be one of the most difficult 
tasks in any TAC® isxplementation. 

£. Outgate 

The Outgate is the module within the DBMS which 
passes messages to the other parts or the systen. The 
Outgate receives traffic from the DBMM and the STATE_MON. 
Frem the DBMM, the Outgatée gets the transaction crder, and 
frem the STATE_MON, the Outgate gets the Area State Summary. 

The data transaction and the resulting Area 
State Summary are paired together at tne Outgate. The 
resulting message is then sent to the Log Recorder for 
inclusion in the DB LOG Reccrd. The Area State Summary is 
also sent from the Outgate to the State Comparison Module. 

The DBMS as descrikted above is straight-forward and 

could be generalized to any database system. it uses 


knewledge to check for the validity of object transitions, 


53 





thus ensuring a valid DB at the object level. Note that the 
validation of object transiticns is considered sufficient 
for the validation of area state transitions (this is stated 
without formal proof). Other than the above-noted special 
functions of the DBMS, it works essentially as a classical 
DENS. 

4. Knowledge Base Management Subsystem (KBMS) 

The Knowledge Base Management Subsystem is the final 
major segment of the TAC* Systen. The KBMS is the 
repesitory and manager for the knowledge that TAC* posesses 
abcut the real world. Most of its functions are analogous 
to those of a classic DBMS, but there are some differences. 

ae Knowledge Base Management Module (KBM&) 

The Knowledge Base Management Module (KBMM) is 
that part of the KBMS which performs the DBMS-like functions 
of getting, updating, and putting records in the Knowledge 
Base (KB). Messages containing updates/changes are received 
by the KBMM from the State Compariscn Module in the Control 
Suksysten. 

The KBMM takes these change messages (Rule 
Transactions) and implements them on the KB. This involves 
first getting the record containing the rule from the KB 


ae. Changes are then made to the rule according to the 
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instructions of the RIX message. A rule may ce deleted, 
added, or its associated response altered. Onice this is 
acccmplished, ‘the record is placed (PUT) back into the KB 
and alog message is sent to «the KB Log Reccrder for 
temporary storage until the next KB dump. 

b. Response Fetch Module (RFS) 

The Response Fetch Module (RFM) of the KBMS is 
used to get the appropriate Rule Response from the KB and 
send it to the Response Driver in the CON Subsysten. The 
input to the RFM is either a rule transaction or an Area 

tate Summary message from the State Comparison Mcdule. sise 
ene ample is a rule transacticn, then the associated 

esponse is attached to the Rule. The Response is copied, 
checked, and sent to the Response Driver. 

MicemOmner tyre of inputscas daneeArea State 
Summary, and when a Summary is received, the RFM uses the 
STATE value to directly access the required record. After 
the record is read, the Response is Sent to the Response 
Driver. Accessing the Response should be fast and easy, 
using a dense index in the KB. 

c. The Knowledge Base (KB) 
The key to the capatilaty and adaptability of 


the TAC® System is the noticn cf a Knewledge Base, where the 
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relations and implications of what the programmers have 
"taught" TAC*® about the real world are stored. The Rules of 
the KB are things which TAC® knews or expects te be true, 
aleng with some consequent results. 

To promote fast response and efficient use of 

tcrage space, the KB is divided into at least four major 
parts: the dense Index; the Object Rules; the Area Response 
Rules; and the Area Analysis Rules. 

The Index organizes the physical data into a 
useful structure, acting as a dense index into the 
relatively sparse Area Response Rule section, thereby 
permitting better use of storage. This is necessary to 
prevent the need to search the KB to locate the required 
recerd, or élse to have a huge file section, much of which 
wculd not b2 used (being empty or replicated data). 

For example, if we used a 16-bit Area State 
Summary, the corresponding number cf different states would 
be 65536 (64K), pecommene 16tn, too large for a small 
computer, even with a hard disk mass storage, since a record 
would be needed for each state. Within the access functions 
of the KBMM and the RFM, the Index is used to map the 16-bit 
number to a much smaller number of records, with the mapping 


being faster than an explicit search. The relaticn between 
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Area State Summary values and Area Response Rules will be 
many-to-one, with relatively few Response Rules. 

An Index for 64K Area States would reguire about 
one Megabyte of storage for the Rule (key) list alone, with 
scmewhat less than that for the Response Record list. Since 
hard disks aré now availible with 5 to 20 Megabyte storage 
capacity, this seems well Within the range of 
nicrecomputers. This would leave the bulk of mass storage 
for the larger Respense records. 

The Area Rule Response Sectacn- Chuene Ke 
contains the reactions of the system to a specific value of 
the Area State. It is easy to store these reactions in 
contiguous records of fixed length, with some breakage 
expected. Actions may be messages to the operator, 
advice/forders to remote stations, or data transactions which 
feed back into the system. All actions are executed by the 
System via the Response Driver andthe Output Spooling 
Precess as described above. 

The Area Analysis Rules are also included in the 
ee. These rules may be considered to be analogous to 
precedures, in that they enable the State Monitor to compute 
a State Summary value. The State Summary value is an 


integer which is the result of the operation of the 
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STATE _MOW, and it sufficiently describes the state of the 
ROT. It is used by the KEMM +o index into the KB Response 
Sum—case. The eperation and use of these rules is deseribed 
JH the section on the Area State Monitor, above. 
The final section of the KB is allccated to 
Object Rules. Object Rules are ased by the Object 
Pransition Validation (OTV) Module of the DEMS tc validate 
state changes resulting fxrcm data transactions. The Object 
Rules represent physical ccnstraints which limit the ability 
tc transtorm =rom one state tc another (@axiaun/aininoua 
epecds, deptrhs., altitudes), as well as known political 
Cemstraints (e.g. (mits cistype "EE are not ,peraedtted to 
operate in this area). Depending upon the amount of 
expertise <he system is designed to have, the Object Rule KB 
may be quite large and require its own index and access 
mechanisas. The KBMM can, however, manage changes tc both 
the Object Rules and the Area Rules guite easily. 
This completes the detailed decriptica of the TAC* 
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C. EXAMPLES OF SYSTEM OPERATION 
1. Data Transaction (DTX) 

The Input Spooling Process (ISP) receives a nessage 
frem the ship's Commmunication Center as the result of an 
Intelligence Report from the Fleet Intelligence Center. A 
data transaction (DTX) is sent to the ISP which states that 
a Soviet Navy AGI (intelligence gathering shir) is operating 
in your area. The DTX is queued in the ISP until the CON 
Input Selector is not busy. 

The Input Selectcr Switch (ISM) receives the 
transaction, sees that it is data, and sends it te the DBMS 
Ingate, where it is again gueued. When the DBMS signals to 
the Ingate that_it is ready for. the. next. message,..the..DTXis-- 
ropwarded . The DBMS determines that the DTX is an object 
Pasnecdet1on, and it calls the Object Transition Validator to 
ensure correctness of the change. 

This particular transaction reflects a change in 
position of the AGI cf about 50nm in 2 hours, for an average 
speed of 25 knots. The OTV module, accessing the Object 
Rules KB, knows that the maximum speed of an AGI is only 20 
Wacts. The OTV sends a message to the operator noting the 
discrepancy between rules and data, but it is programmed for 


data supremacy; thus the DTX is allowed. The transaction is 
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Sent to the Outgats, where it is coupled with the Area State 
Summary. 

The Area State Monitor (STATE_MON) determines that a 
change in the AGI's positicn changes the Area State. It 
calculates the new Area State Summary, and sends it to the 
DBMS Outgate. At the Outgate the Area State Summary is sent 
to the State Comparision Mcdule and the compdined DTX/Area 
State Summary is sent to the Log Recorder. 

The SCM compares the incoming state with the old one 
and determines that a new state exists. The new state is 
sent to the Response Fetch Module, where the correct 
response is accessed and fcrwarded to the Response Driver. 
The Response Driver determines that the destinaticn:- of -the 
response is the operator, and it sends the message to the 
Output Spooling Process (OSP). The OSP sends the message to 
the TAO, who reads it and notes that the recommended 
response is to set a special Emission Control posture to 
restrict the amount of technical intelligence availible to 
the AGI. TAC*® also advises the TAO to alert his own 
TECHELINT collection team, and specific emitters of interest 
on the AGI are noted. 

The reaction of TAC*® to the DTX is now completed, 


and the TAO has received scund advice. Note that TAC* also 
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warned the operator of possible inaccuracy in the data when 
the OTV did net completely validate the transaction. 
2. Rule Transaction (RTX) 

Shortly after the processing of the DTX above, 
ancther message is received in the Communicaticns Center. 
The Fleet Commander has crdered that all AGI's of a certain 
class be closely investigated for néw capabilities. The AGI 
in the AOI is one of this type. 

Up to the Input Selector, the flow is the same, but 
now the message 1s sent to the State Compariscn Module 
because it 1s a Rule Transaction (RTX). The ISM also sends 
the RTX to the KBMS which guickly enters it into the KB. At 
the SCM, it.-is determined that the new Rule affects the 
current area state. The transaction is sent to the Response 
Fetch Module for action. 

The RFM accesses the Response Dart of the 
transaction, and formats it for output. It is then sent to 
the Response Driver, which in turn sends it to the OSP for 
reporting to the operator (or the TAO). Tae TAO now is 
aware that a message has been received dE rece ing 
intelligence gathering action against the AGI. Appropriate 
steps are listed to put the ship on its maximum readiness 


Eeetang £Or the coming task. 
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TAC* again has reacted exactly as desired in 
response to a change in knewledge. The sare istye CO” Cuic KLy 
react to the change is crucial, as failure to do so may have 


fatal results in the tactical environment. 


62 





IV. DESIGN ANALYSIS AND RECOMMENDATIONS 


ST TS I IE CII, TG IERIE IS SS eee 


A. PREFACE 

When analyzing any design, it is important to consider 
the original goal and determine how closely one has come to 
eenieving it. Our specific goal was to design, at the 
conceptual level, a computerized decision-support system to 
asSist tactical commanders in the decision-making process. 
We feel that TAC* is such a design. However, with any new 
system, both advantages and disadvantages are accrued, and 
the TAC*® system 1s no exception. Therefore, this chapter is 
an attempt to impartially consider both positive and 
negative aspects of our design. Such areas as applicable 
domain, modular design, real-time response, and systen 
intelligence are examined. We will also discuss those 
system extensions which, in our opinion, are feasible and 
would be relatively easy to implement. Due to continuing 
pregress in areas such aS magnetic bubble memory, 16-bit and 
32-bit microccmputers, and systems of computers, we contend 
that our "projections" of TAC*'s reliability should be 
regarded as more than mere speculation. We do accept as 
fact, though, that the ultimate test of reliability lies in 
the successful implementaticn of our design. 
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B. ADVANTAGES OF TAC* 

A TAC* prototype system can offer the lower-level unit 
commander an additional tocl for use in his decision-making 
prcecess. This system is appiicable to the tactical 
environment and has the capability to intelligently process 
large amounts of data in real-time. 

1. Applicable Domain 

TAC* is a knowledge-based decision-support systen. 
We believe that such a system is applicable to a specific 
domain when the following criteria are net: 

e There exists a large amount of information 
mec. the specrilc dcmain. 

e Such informaticn is capable o£ being 
deccmposed into either data about the domain or knowledge 
abcut the domain. 

e The control system strategy 1S adaptable to 


computer operation in "domain real-tine." 


There is general agreement that the tactical 


environment generates large amounts of information fron 


higher-level commanders, from active and passive 
intelligence gathering sources, and from changing 
environmental conditions (tc name just a few). Information 


frem any of these origins may easily be represented as 
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either pure data, which is stored in a database, or rules tc 
march the data must ccnforn. Due to the relatively smali 
number of available options for a particular tactical 
situation (current target, available weapons systems, etc), 
the system control structure will be able tc operate 
PeEIciently. Lis, a knowledge-btased decision-support 
System is, theoretically, well suited for application in the 
tactical environment. Implementation and utilization will 
be the basis for determining if such a system is 
realistically applicable in a tactical situation. 
2. System Intelligence 

A primary goal behind the development of TAC* was to 
d2vise asystem capable cf assisting the tactical unit 
commander in his decision-making process. As such, the 
system first had to be intelligent. That is, it had to be 
capable of storing large amounts of data, knowing what that 
data meant, and how it could be used. System intelligence 


had to be intrinsic, rather than provided by the human 


element. BY correlating applicable rules and data, 
intelligenc2 has been designed into the systen. Processing 
data, analyzing changes, and formulating alternative 


sclutions can be extremely time-consuming for the human, but 


should be accomplished by TAC*® in less time. The ultimate 
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benefit gained will be to allow the commander more time to 
devete to those «tactical considerations which cannct be lefce 


to the computer. 


We believe that machines should not be considered as 
replacements for humans. Rather, the effectiveness of 
combining human and machine intelligence should be 
Maximized. TAC® should allow the computer +o perform those 
furctions which ar2 time-ccnsuming and prone to human error, 
while preserving the human factcr in areas of judgement and 
experience. Such integrated inteliigence maximizes the 
effectiveness and efficiency of the decision-making process. 

We feel that the TAC* _-system _1s. a logical 
application of decision-support principles to the area of 
mectics. While NIDS gathers information and presents it to 
the human operator in a way that promotes analysis, TAC* 
will do much more. TAC*® will analyze the situation that the 
data represents using infcrmation stored in its knowiedge 
base and racommend responses to the operator. TAC* will not 
be a glorified information-handling system; it will be an 
expert in the area of tactics and weapons employment in the 


tactical environment. 
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The obvious questicn is "Why not extend the present 
System rather than introducing a new one?" We contend that 
NTCS cannot be extended to achieve the speed of learning 
Which our system will offer. This is because NTDS isa 
static software package; once a version is loaded, system 
response is fixed until an updated version is distributed. 
On the other hand, TAC*® shculd learn a completely new tactic 
in a short period of time by simply updating its knowledge 
base. 

3. Distributed Systen 

A fully distributed cemputer system is one in which 
+he hardware (HW), software (SW), and data are resident at 
watrews local sites. It is, therefore, a "stand alone" 
System which, if part of a network, communicates with other 
Sites vila messages. The characteristics of TAC* classify 
the system in this distributed category. One of the most 
important benefits derived from this type of system is the 
availability of a complete computer system which can be 
deveted entirely to the needs cf the local site. In our 
tactical environment scenario, this means that the local 
commander does not have to compete with other commanders 
(outside of his Area of Interest) for the use of the 


computer systen. 
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Given the alternative between a distributed or a 
centralized systen, the former was chosen for TAC* even 
Baemaieettadi sional wilitary control of subordinate units has 
been extremely centralized. As specified in Chapter I, we 
believe that the independent operaticn of tactical units in 
any future conflict will promote better control up, rather 
¢han down, the chain of command. This is not to say, 
theugh, that higher level strategic decisions will not be 
PomenCcOmung in the form ef specific orders. Whether 
tactical independence is reccgnized and planned for by the 
command structure or cccurs, by necessity, after the fact is 
immaterial. We believe that independent unit operation will 
be unavoidabie and the distributed..system.will..be the. 
principal factor responsible fer survival in tne tactical 
envirenment. 

Planning a system which supports independent unit 
Opération provides the most flexibility te the tactical 
commander. However, the tailoring of a "stand-alone" systen 
does not preclude its use in centralized command structures. 
Rather than a limited applicability, TAC* should be equally 
applicable in either centrally controlled or independent, 


isclated scenarios. Consider the f£cllowing situation: 
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A tightly controlled network of computers is 
devised to command a tactical group in battle. In the first 
minutes of hostile action, the Net Control Station is put 
out of action by enemy fire and electronic jamming on the 
digital data link is severe. Local tactical units, their 


sophisticated centralized computer systems rendered useless 


by the confusion, damage, and jamming, overwhelm the 
commanders with false and superfluous information. In the 
next few minutes, the enemy launches a major offensive 


s*rike and severe losses to friendly forces are suffered. 


Because such an occurence is possible, we designed a 
system capable of egither independent or grcup operations. 
An Input/Output system based on message-passing was included 
morpmemciciency and flexibility. TAC® was concéived asa 
modular system, with each module or node performing a 
specific function. A group of nodes, communicating by means 
of messages, would ccnstitute one ccmplete system called a 
"cluster." Nodes will perform the functicns of Input, 
Output, Control, DB Management, and KB Management. Ciusters 
will be capable of inter-ccmmunication by means of messages 
passed between respective I/O nodes, using any dus protocol 
deemed appropriate, thus forming a network of clusters. We 
believe this is this is the best way to achieve reliability 


and modularity at the least te 









4. System of Computers 

The design of TAC* has been highly modularized to 
allew for the flexibility of implementing it as a system of 
microcomputers, rather than using a large mainframe. 
Instead of devoting a fixed amount of core memory for the 
DEMS, another fixed amount for security and protection, etc. 
one small computer may be used for each major function or 
module. For example, the Area State Monitor could be 
configured to have its own set of rules which it would use 
to derive the Area State Summary. The rules would reside in 
one microcomputer whcese sole responsibility would be to the 
Aeea State Monitor. In essence, such a configuration could 
be viewed as being a network within a network. The inner 
network would be exclusively devoted to the tactical unit, 
with the various unit's systems combining to form a "global" 
network. Sheuld one of the machines in the inner network 
malfunction, only a portion of the system's total capability 
would be lost. Further, system maintainability and the 
isolation of component failures should be more simplified 
than those associated with a large, centralized systen. 
Additionally, the use of a Simple control structure with a 
small amount of intrinsic knowledge should improve the 


chances of a hardware deficiency being repairable by "plug 
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and go" strategies. Since nearly all of the system control 
infcrmation is included in the KB, should any of the several 
CPU's fail, replacing it should be straightforward and easy. 

Note also that the mechanism of ene GontroL 
structure 1S simple and consistent. Adaptability is 
achieved by changing KB entries dynamically rather than by 
complex control structures. These simple control mechanisn 
instructions could be pregrammed in ROM-type storage to 
prevent accidental erasure from any source. 

From the very beginning, we wanted to design a 
system small enough in price and size to afford its use at 
the lowest levels of command. This was another reason for 
uSing the modular design. In our opinion, TAC* can be 
implemented on a cluster cf single-board computers. 
Alternatively, a single minicomputer might suffice for speed 
and size but would gain nothing from the message-passing 
independence of the nodes, which with SBC's implies "plug 
and gc" repairs. 

Th2 amount of required storage for the database and 
knewledge base is ancther ratter. A reasonable estimate of 
required storage is, we feel, about 20-50 megabytes. 
Obviously, semiconductor RAM wculd reduce access time, but 


would increase system cost. A hard disk would bring the 
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price down somewhat, but access time would suffer. Also, 
the feasibility of the hard disk to the tactical environment 
is suspect as they = fairly susceptible to shocks. We 
feel that magnetic bubble memory devices are, or soon will 
be, dense, cheap, and fast enough to solve this problem. [In 
addition, it is non-volatile which would hasten recovery 
frem crash2s and faults. 

The overall ccncept c£ a "system of computers" 
shculd prove to be more conducive to the tacereal 
environment if, ECG No cther teascn, than its portable 
characteristics. 

5. Real-Time Response 

Much effort has been devoted to develop a knowledge- 
based computer system which responds in real-time. One of 
*he better known systems to date is MYCIN (Stanford 
University, Wore Ret Sj, which was developed as a 
diagnestic and therapy consultant for bacterial infections 
teerne Hplood. Many of the basic concepts from MYCIN are 
alse ¢vident in TAC*, however real-time response as defined 
for the former was not adequate for our tactical systen. 
The impact of this re-definition of real-time response was 
+he necessity to simplify the system control mechanism and 


he various interfaces Wintout the loss of systen 
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capabilities. Certainly, recent advances in the speed of 
medium and small computers should prove to be extremely 
helpful in a successful isaplementation. Bus, more 
mye cEtantly, it will be the proper combination of data 
structures, links, andthe method of treating system rules 
in the same manner as data which will achieve tactical real- 
time system response for TAC*. 

We believe that this real-time response capability 
1S a most important characteristic of our system, for this 
alcne enables the TAC* system to bea useful tool for the 
lower level commander. Similar "intelligent" computer 
systems, like MYCIN, may be considered by some to be more 
sophisticated and powerful than our particular design. 
However, it is just this sophistication and power, not to 
merticn sheer size, that makes such system's real-time 
response inappropriate for the tactical environment. TAC* 
is intentionally designed without assigning aiternative 
Pecbabmiie es (OF certainty factors), an interactive query 
capability, and other features used to "prove" te the human 
that the computer's recommendation is the "rigat" answer. 
In the tactical environment, we hold that the decision-maker 
doeés not have the time to debate relative probabilities with 


either another human or a machine. Thus, a tactical real- 
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time response can te achieved, DUG ac che °Expense oe 
forfeiting a more sophisticated systen. 

It should be noted, however, that an interactive 
capability is recognized as being an important feature. 
Such a capability may easily be incorporated for use in 
training situations. As the individual becomes proficient 
with the systen, the logic followed by TAC*® to make a 
particular recommendation could pe examined by the trainee. 
The more recommendations TAC*® makes which the individual 
agrees with, the mere that individual will "trust" the 
system's recommendations in a real-world tactical situation. 

The Capabilities of a TAC* system can be compared to 
other systems like MYCIN, NIDS, or WWHCCS. We believe that 
these systems fall short in adaptability, and more 
specifically, adaptability in tactical real-time. The 
adaptability of our design was the prime motivation for its 
conception, with all other considerations being secondary. 
In this area, ae feel that TAC* promises to be far better 
than either NTDS or WWMCCS, which are not at all adaptable 
in the sense we have defined. 

6. Generalized Concept of TAC* 
Many computer systems have been designed ‘for 


specreic problems. The result of such systems is limited 
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application areas. While the original concept of TAC*¥ was 
Ser peovide a tool for the tactical commander, the ultimate 
design was conceived to be general in nature. Due to the 
method of treating data, rules, and changes to both 
identically in our design, the basic system may cre used in 
any number of other application areas. Data and rules need 
Meotemmem nestrtcted to those pertaining to our tactical 
environment scenario. Whether the data and their 
corresponding rules apply to warfare planning, medicine, 
autemctive production, PIVvemcOry COnthO wmCheair tratfic 
centrol makes no difference to our systen. All types of 
information are processed in the samé nanner. Such systen 
capability should prove to be an invaluable asset when one 
considers diminishing Operating kudgets combined with 
increasing personnel costs. 

Perhaps more than anything else, TAC* is a point of 
origin from which many cther systems can develop. We 
contend that TAC® is a notion of how intelligent computer 
systems should be designed to achieve maximum systen 
admireabilisy. Actual implementations of TAC* will vary, 
especially in the internal operations of the DBMS and the 
Koes. We believe that the general concept of our design is 


a significant and unique characteristic of the systen. No 
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System re-configuration is needed to implement totally 
different types of problem environments if the basic system 
is properly implemented. All one need do is to identify to 
TAC* a new Database and new Knowledge Base which are 
applicable to the desired domain of interest. 

C. DISADVANTAGES OF TAC* 

The acceptance or non-acceptance of TAC* may be viewed 
as being dependent upon two major factors: real and 
perceived system disadvantages. Real disadvantages are more 
2asily isolated and, hopefully, can be negated by system 
modifications. However, perceived disadvantages are not 
easily overcome. Human receptiveness will probakly be more 
crucial than technical system limitations. 

1. Human Receptiveness 

Even though computer technology has been 
inccrporated into washing machines, watches, children's 
toys, video games, etc. many people still view the computer 
as a mysterious "black box." Very little resistence to 
computerization is evident so long as tne computer provides 
entertainment or decreases the human workload. However, the 
slightest hint that computers might participate in the human 


decision-making process results in auman resistance. 
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TAC*X, being typified as a knowledge-based decision- 
Support system, will prcebarly be regarded by many people as 
a threat to the “ultimate” human caaracteristic: the ability 
+o reason. Such people will probably not reccgnize that 
TAC*® and similar intelligent computer systems are merely 
attempting to simulate and augment the human decision-making 
pEccess. Regardless of the purported sophistication of the 
system, and more specifically the system's software, the 
computer only does that which the human has programmed it to 
do. MYCIN is led to a particular diagnosis based upon pre- 
assigned certainty factors and current test results, both of 
which are input to the system cy qualified medical 
personnel. Likewise, TAC® makes a "decision" Or 
recommendation based upon the current answer to various 
OMBAT... LF" questions. The list cf possible answers are 
pre-programmed into the system Ly humans. 

Such a simple and logical explanation may fall on 
deaf cars, though, as most humans are irrational when they 
feel threatened. Therefore some, and perhaps the majority, 
of people may simply refuse to accept TAC* for what it 


really is: another tool at man's disposal. 
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2. Complexity of System 


Because TAC*® has been highly sedularized, there wili 
necessarily be a significant amount of data exchanged 
EFetween modules. Even though much effort was devoted to the 
Simplification of the modules and their interfaces, the 
complexity of the tactical environment itself imposes a 
limitation upon system simplification. Although the tasks 
of the individual modules are quite simple, the resultant 
overall design is more complex than that which was 
Originally conceived. 

Complexity has several disadvantages and TAC* will 
not be immune to problems. A complex deSign is more 
expensive in terms of both dollars and man-hours spent to 
implement and maintain, increases the possibility of systen 
“hugs™, is more difficult for the average person to 
understand, and therefore, sso accept, and normally 
experiences a higher incidence of “software tampering" than 
does a less complex design. 

People tend to rélate complexity to reliability. 
Due to the stakes involved in the tactical environment, 
System reliability is a nen-negctiable requirement. The 
percertion of design ccmplexity aay also create the 


perception of an unreliable systen. 
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3. System Control 


Just as in the human decisior-making precess, the 
effectiveness of a computerized decision-support system is 
Goeececly belated to the quality of the information used to 
make a particular decision. Therefore, some method of 
System control must be enforced to insure that only 
authorized rule changes are input, only reliable data 
updates are made, andall unauthorized access attempts are 
denied and reported. Such protection and security 
reguirements are not easily accomplished, as evidenced by 
the vast number of both civilian and military research 
prejects that are ocn-going in these areas. Further, the 
reliability of data seems tec imply that some type of formal 
or informal mathematical probability must be used. Anything 
Shert of probability is mere speculation. 

The result of making an error in the tactical 
eanvirenment could be fatal to the single unit and could have 
disastrous effects on the naticnal goals of the forces 
invelved. Because it is feasible to configure TAC* in such 
a way that it could actually ccntrol various weapons 
systems, some form of over-ride (or "fail-safe") mechanism 
must be incorporated to prevent a potential catastrophe from 


CCGUreng. In its basic fcrm, TAC*® is characterized as just 
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ametner tool. But in this advanced form, TAC*® is both the 
meot and the wielder of the tool (subject to human 
Supervision). If it is net properly used, unpredictable 
action may result. 

Total system control is mandatory, but may not be 
feasible with current technolcgy cr human disregard for 
Gaver cn. 

D. RECOMMENDATIONS 
1. Implementation 

Implementation of the TAC* system should be done as 
a cluster of 16- or 32-bit single-board computers, using 
magnetic bubble memory as storage for the DB and KB. A 
language suited to the message-passing environment and which 
is amenable to bit-checking operations should be used. 

2. Extensions 

An interactive query system (IQS) similar to that 
used by MYCIN might be useful (See previous discussion in 
chase Chapt er). Such a capability could be used by the 
tactical commander or by a student to extract from the 
system the path of logic used in reaching a particular 
decision. This information will be available in the form of 
Log Recorder entries. An IQS nodule could access the Log 


file as its own database, Wee Cead=only protection, of 
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course. Because of the time ccnstraints of the tactical 
commander, CnlSteapoctmMeaye nagne be lLigited tc training 
purposes. 

Additionally, the Log file could be read ky an Error 
Analysis Module which would detect, through comparison 
between recommendations and actual events, which rules of 
the knowledge base were inconsistent with actual 
occurrences. These rules could be flagged to the operator 
now, COLESCtION, thus providing a valuable service in 
maintaining the accuracy of the knowledge base. 

A capability for the system to develop rules on its 
own could also be included. Rule generation could be 
accomplished by rote learning or by the laws of induction 
and deduction. This might present a problem to the 
tactician in that he would not know exactly what rules 
explicitly exist in the knowledge base, but TAC*® cculd 
identify these to the TAO as logical extensions to its 
pregrammed rules. 

Finally, TAC* could be extended to implement the 
reccmmendations or the decisions which it makes. TAC* would 
then te a decision-making system, rather than a decision- 
SUPfort systen. Constraints could be placed on this 


Gagapetity, Sueh as pOSitive control cr control by negation. 
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Pewecone, the jcapability cf a TAC* platfcra tc respond 
quickly to all threats would be greatiy enhanced. 

3. Warning 

When a computer system enters the realm of tactical 

decision-making, it becomes “responsible” for many human 
lives. This situation will not be borne any easier as 
Situations become more complex. What is placed in the 
knewledge base cf a TAC* system must accurately reflect the 
policy of the military and be approved by a competent 
authority. Some method of testing or verifying the 
correctness of the system must be considered and used. This 
must be accomplished before TAC* assumes the role of 
ccmputerized decision-maker. 
E. CONCLUSION 

In the final analysis, we kelieve that we have 
acccmplished that which we set out to accomplish. The top- 
level, conceptual design of a knowledge-based, intelligent 
decision-support system has been presented and the bases of 
our design have been made known. The proposed system, we 
feel, will be smail, flexible, and adaptable. It is our 
Opinion that TAC*® will prove helpful in the design of future 


tactical command and control systems. 
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Comeveiicd Work is needed to refine the concert and to 
test its practicality by various implementation strategies. 
However, the basis for TAC® mnust be kept foremost in any 


attempt at implementations: intelligence and adaptability ia 
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